EZP-26680 INI Cache files are generated with wrong filepaths #1269
Conversation
When publicAPI calls are executed via Symfony controller and for example a user is created via UserService, this Signal is triggered into legacy System cache management. The eZINI::instance() is called inside user datatype which checks site.ini cache file. In the cache file are relative paths to override ini files which do not work because application is in Symfony context (and not cwd in legacy). The override file is not found via file_exists() and the new generated cachefile is w/o override files cached, which "destroys" legacy application.
|
-1 Might be missing legacy fallback call which would make sure folder is right for legacy? |
|
I was thinking along the same lines... |
|
The requested ini file is always stored absolute, the additional one's relative. So there is a inconsistency on this... <?php |
|
IIUC, |
When publicAPI calls are executed via Symfony controller and for example a user is created via UserService, this Signal is triggered into legacy System cache management.
The eZINI::instance() is called inside user datatype which checks site.ini cache file. In the cache file are relative paths to override ini files which do not work because application is in Symfony context (and not cwd in legacy).
The override file is not found via file_exists() and the new generated cachefile is w/o override files cached, which "destroys" legacy application.